1. Field of the Invention
The present invention generally relates to computer software assemblies composed from a collection of independent software components. More specifically, the present invention relates to a method for dynamically modifying or replacing components in a running assembly.
2. Description of the Related Art
Software components have emerged as a software design methodology that borrows concepts from software patterns, object oriented design, and software frameworks. Generally, a software component is a unit of independent deployment that encapsulates a defined set of functions. For example, a component may provide a set of spell checking services to a word processing program. A party developing a word processing program may develop a spell checking component, or may obtain one from a third party. Because components may be deployed independently, the same component could provide spell checking services to an email program, or any other program that required these services. A common way to implement a component is as a class object using object-oriented programming languages such as C++, Java®, or Smalltalk, among others.
The functionality of a software component is specified by rules that describe an interface to the component, any preconditions that must be followed before invoking a particular function provided by the component, and any post conditions that will exist after a function is executed. A useful way to view these conditions is as a contract between a user of a component interface and a provider of an implementation of the interface (i.e., of a component). The contract states what the client must do to use the interface (preconditions), and states what the component must do to provide the services promised by the contract (post conditions).
In component based design, interconnections (or contracts) are formed between multiple components. An assembly of components may be “wired” together according to interface specifications and rules. A common contract is just an output “wire” that comes out of one component and is connected to the input “wire” of another component. Together, the components, and connections between components, form a working assembly. In composing a component assembly, a developer explicitly wires the components together so that each component operates correctly within the assembly as a whole. For example, the assembly may be “powered-up” or “powered-down” using a sequence of management commands hard coded into a particular assembly.
If the assembly is static, then connections may be formed when the components are wired together and do not change. In such a case, the component assembly functions as a single construct, wherein contract formation and the wiring between components are fixed as part of the assembly. In order to modify or change a component, the complete assembly must be shut down before any modifications may occur. Further, the sequence of management commands used to start or stop the assembly must be modified to reflect the change.
In a dynamic or on-demand assembly, the interconnections between different components may change while the assembly is running. Thus, contracts between different components may be formed and broken, perhaps many times. For example, consider a contract between a client component and a server component, where the client transfers data to the server, and then the server manipulates and returns the data. Each time the client transfers data to the server, a new contract is formed. Before a contract is terminated, the client may need to receive the current state of the data or need the server to certify that it has destroyed any copies of the data once it is returned. Simple contract time-outs are not sufficient.
Further, to change or modify the components of a dynamic assembly, information regarding each component of the assembly must be available. Each time a component modification or replacement is desired, an administrator must determine appropriate sequence of management commands to modify or replace a component. However, if performed incorrectly, the administrator may disrupt the assembly causing it to crash, or data to be lost.
Accordingly, there remains a need for a method for modifying or replacing components in a running assembly of software components.